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REMARKS 

The Examiner is thanked for his Office Action. The Examiner is thanked in particular 
for the specific references to Eskafi's teachings used to support each rejection, 
Claims 1-25 are pending in the application. All claims were rejected. 
The arguments presented in the previous response are reiterated and incorporated 
herein by reference. 



35 USC 8 102 - Anticipation 

Claims 1-19 and 22-25 were rejected as anticipated by Eskafi et al (USP 6,438,223, 

hereinafter "Eskafi"). These rejections are traversed. 

Independent Claim 1 requires *a service node which monitors services 
and uaing the Bervice node, monitoring signals to the terminating remote 

communication." Nothing in Eskafi appears to teach or suggest this feature. The 
passages of Eskafi do reference a Service Control Point (SCP), but a typical SCP does not 
monitor services, and typically provides a database lookup function and control functions, 
but no monitoring functions - and Eskafi does not describe that the SCP or any other 
component actually monitors services. In fact, the term "monitor" does not appear in 
Eskafi at all. 
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The current Office Action appears to rely on Eskafi's SCP as the claimed service 
node, and cites specifically col. 4-5 lines 60-13, col. 5 lines 34-57, and col. 13-15 lines 
60-4. A careful analysis of these passages does not indicate that Eskafi's SCP monitors 
services. For convenience of reference, the portions of these passages that reference 
Eskafi's SCP are reproduced below, while the portions of those passges that do not 
reference the SCP are omitted* 

Eskafi's col. 4-5, lines 60-13, in relevant part, describe the SCP as follows (note that 
although this passage references "Fig. 2A"; Eskafi does not have a Figure 2A): 

FIG. 2A illustrates the LRN scheme for 
implementing Service Provider Portability .... In 
addition to the SCP database, each service 
provider is provisioned with an additional LNP- 
SCP database for storing the routing information 
for a ported subscriber- „. When a call to a DN 
that haa been predefined as LNP portable, the 
Service Control Point's (SCP) service logic 
programmed in the exchange will initiate an AIN 
or IN based LNP query to the LNP-SCP to obtain 
the LRN for the destination exchange to which the 
DN that has been ported. The queried LRN is then 
returned to the exchange to route the call 
accordingly. 
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This passage describes the "SCP Database " but does not teach or suggest that the SCP 
(or the SCP's service logic) monitors any services. 

Eskafi's col. 5, lines 34-57, in relevant part, describe the SCP as follows: 

At eome point, a connecting exchange must look 



up the ported information from one of the LNP- 
SCPs in order to complete the circuit to the 
ported location* «. In step (2) , thiB induces a 
Stp to lookup lrn(dni) from lnp-scp. 



This passage describes lookups into the SCP database, but again does not teach or suggest 

that the SCP monitors any services at all. 

Eskafi's col 1 3-14, lines 60-4, in relevant part, describe the SCP as follows: 
Thia will trigger a query to an LNP database 



(XiNP-sCP) . The query iB done via a STP in which 
the ISUP part is conventional, but the TCAP part 
of the SS7 message enables lookup to either an 
ONS or LNP database and the STP returns a query 
result to the exchange. 



Again, nothing in this passage leaches or suggests that the SCP monitors any services at 



In specific response to Applicant's previous argument on this point, the present Office 
Action states "Eskafi does describe that the SCP (service node) and IP monitors services 
(col.3 lines 54-65, col. 4 lines 14-21, and col. 9 lines 36-51) " These passages are 
analyzed as follows. 



all. 
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Col 3, lines 54-65, reads, in relevant part: 

... The IP Interacts with SCP to have the 
forwarding of DNl to DN2 entered into the SCP. ... 
Subsequently, when a call to DNl is received in 
- XI, it will trigger XI to obtain the call- 
forwarding information directing to DN2 by 
performing a lookup on the SCP. ... 
This passage indicates that the "IP interacts with die SCP" to enter information into the 

SCP, and that a lookup is performed on the SCP. Nothing in this passage teaches or 

suggests that the SCP monitors services. 

Col. 4, lines 14-21 , reads in its entirety: 

The Intelligent network-based call -forwarding 
scheme improves on the switch-baaed scheme in 
that the call -forwarding information is not hard- 
coded into the exchange but rather retrievable 
from a more flexible database. The service need 
not be set up at the original access point LI but 
could be set up by the subscriber from any access 
point including L2 that has access to the IP. 
Otherwise, it still has the same disadvantages as 
that of switch-based scheme. 

This passage says nothing specific about the SCP at all, and has no teaching or suggestion 
of monitoring services. 
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Col. 9, lines 36-51 reads in its entirety: 

In an Intelligent or Advanced Intelligent 



Network (IN/AIN) , a set of databases 60 as 
provided by one or more Service Control Point 
(SCP) such as 62, 64 may be installed as a point 
in the SS7 network. The SCP 60 is a database for 
providing service related information or number 
porting information and is available for an 
exchange to retrieve information dynamically via 
an STP. As described earlier, in a network where 
service provider portability has been 
implemented, a fcNP-SCP 62 has been added to store 
service provider number porting information. In 
one preferred embodiment of the present 
invention, a database OSCP 70 for storing 
information about ported number across arbitrary 
access points is also provided. The OSCP 70 is 
connec table to the OSTP 50 via the SS7 network 40 
and/or via a high-speed connection 72. The set of 
databases 60 is maintained by a Local Service 
Management SyBtem (&SMS) HO. 



This passage indicates that Eskafi's SCP, and its variations, serves as a database, storing 
information and accessible for lookups. Like the other cited passages, this one does not 
teach or suggest that the SCP monitors any services. 
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So, although the Applicant has studied closely the entirety of Eskafi, and the passages 
cited by the Examiner in particular, Eskafi does not teach or suggest "using the service 
node, monitoring signals to the terminating remote communication." Since a service 
node as claimed is not taught or suggested by Eskafi, the anticipation rejection must fall, 
and Claim I should be allowed. Similarly, Claims 2-U, which depend (directly or 
indirectly) from Claim 1, should be allowed. 

Independent Claim 12 requires "a service node connected in the signal 
path said lnp database supplying the LRN instruction to said service 
node ... in which said service node provides network services to said 
! terminating remote communication device.*' Nothing in Eskafi appears to teach or 

suggest a service node connected and operating as claimed, Applicant has studied the 
passages cited by the Examiner in response, but again the Applicant can find nothing in 

i 

Eskafi that describes the claimed limitations. Since a service node as claimed is not 
taught or suggested by Eskafi, the anticipation rejection must fall* and Claim 12 should be 
allowed. Similarly, Claims 13-20, which depend (directly or indirectly) from Claim 1, 

i 

should be allowed. 

i 

l 

! 

t 
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Applicant specifically notes that with regard to dependent claims 2, 13, 14, and 23, 
the claimed service node is identified as an SCP. A typical SCP, as noted above, may 
perform lookup or control functions, but does not typically perform the other claimed 
functions. The American National Standard for Telecommunications - Telecom Glossary 
2000 (see http://www atis.org/tg2k/ ) defines an SCP as "An entity in the intelligent 
network that implements a service control function," As SCPs are not known in the art 
for performing the functions described and claimed by the present application, and Eskafi 
fails to describe these claimed functions either, these functions cannot be attributed to the 
SCP described in Eskafi. 

35 USC 6 103 - Obviousness 

Claims 20 and 21 were rejected as obvious over Eskafi. These rejections are 
traversed. 
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The Examiner correctly notes that nothing in Eskafi discloses that the service node 
monitors the communication for billing purposes. In fact, nothing in Eskafi appears to 
teach or suggest any service node, as claimed in independent claims 12 and 21 , that 
monitors communications as described (as more fully discussed with regard to claim 12, 
above). Further, with regard to claim 21 t nothing in Eskafi appears to teach or suggest 
"in response to the LRN, creating a service node.*. .** (emphasis added). As the 
features of claims 20 and 21 are not taught or suggested by Eskafi, these claims should be 
allowed, as should claims 22-25, that depend from Claim 2L 

As noted above, the Examiner is respectfully requested to identify which elements in 
Eskafi are used to meet each of the claim limitations - and in particular, which element in 
Eskafi corresponds to the claimed service node. If the undersigned has overlooked or 
misinterpreted a relevant teaching in Eskafi, he would be grateful for the Examiner's 
identification of the error. 
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SUMMARY 



If any issues arise, or if the Examiner has any suggestions for expediting allowance of this 
Application, the Applicant respectfully invites the Examiner to contact the undersigned at the 
telephone number indicated below or at manderson@davi$tnunck.com. 

The Commissioner is hereby authorized to charge any additional fees connected with this 
communication or credit any overpayment to Davis Munck Deposit Account No. 50-0208. 



P,0, Box 802432 

Dallas, Texas 75380 

(972) 628-3600 (main number) 

(972) 628-3616 (fax) 

E-mail: mandersan@davismuncfccom 



Respectfully submitted, 



Davis Munck, P.C. 





Matthew S. Anderson 
Registration No, 39,093 
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